Application virtualization enables complex software to be delivered as self-contained executable files which can run instantly from any data source with zero installation, i.e., copying individual files and settings to the computer system. Application virtualization can provide many benefits, depending on the implementation. For example, using application virtualization, large applications such as MICROSOFT® OFFICE® may be streamed from a shared network drive without any specialized client or server software. Using application virtualization, virtualized applications may be run in managed or unmanaged MICROSOFT WINDOWS® environments without requiring elevated security rights. This allows stronger security to be implemented by allowing applications that ordinarily require administrator rights to run on locked-down user accounts. A degree of isolation is imposed on virtualized applications, thereby protecting the local client computer against changes to the file system and registry for both custom developed and commercial applications, enabling true separation of application and operating system. Some implementations of application virtualization, during the process of virtualization, create a single secure executable file (a “container” file) which encapsulates all registry and file system changes associated with a normal installation.
The container file for a virtualized application may be large—a file size of hundreds of megabytes to a gigabyte or more is common. Thus, while application virtualization eliminates the need to install an application, there can still be significant time associated with downloading the container file, even using a high speed network connection. Users of these large applications typically do not download the application for each use; instead they store and run local copies (whether on- or off-line). There is, therefore, a need for determining whether the last-downloaded version of an application on the client computer is current, and for updating the application by downloading a new version if it is not.
Typically, to determine if an update is needed, a query is sent to the application update server. If a version check reveals that an update is available, the entire updated container file is downloaded to replace the old version, regardless of how small or large a change has been made. The time for downloading the update is as large as (or often larger than) the time required to download the old version.
The problem of minimizing the time required for updating large files and large sets of files occurs in other situations as well. Another example is the synchronization of files among a set of computers that share common data and user files. Such synchronization can be needed between the files on a user's desktop (non-portable) and laptop (portable) computers as well as among a set of machines belonging to the members of a workgroup or company. Synchronization is also needed to maintain “mirror” sites for servers where heavy downloading demand is supported by creating a set of alternative servers providing identical files.
One tool for managing file updating is provided by Rsync, an open-source software package available for Unix and related operating systems. The receiver (whose file copy needs to be updated) splits its copy of the file into fixed-size non-overlapping blocks, and computes the MD4 hash for each block plus rolling checksums for the entire file using file segments that are the same length as the block size. The receiver sends the hash codes and rolling checksums to the sender (the update server that has the update file). The sender computes rolling checksums by the same method on the update file and compares its rolling checksums with the set sent by the receiver to determine if any matches exist. If they do, it verifies the match by computing the MD4 hash for the matching block and by comparing that as well. The probability of a match for both the checksum and hash for blocks that are not identical is extremely low. The sender then sends to the receiver those blocks that do not match any of the receiver's blocks, together with assembly instructions on how to merge these blocks into the receiver's version to create a file identical to the sender's copy. If the sender and receiver versions of the file have many blocks in common, relatively little data is transferred to synchronize the files.
Rsync also supports other features including data compression/decompression to further reduce the amount of data to be transmitted and encryption/decryption for data security.